Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/mod0001.arc/ROMDOOR.DOC

Text File | 1992-02-19 | 14KB | 349 lines

                       * CD ROM LOCAL/REMOTE DOOR *
               (C) Jim Snowden, 1991.  All rights reserved.
                        Helix Software Foundation


* What it is *

   This program allows the user to search, unpack specified groups of files,
   typically on a CD-ROM.  It handles global and group searching for
   keywords.  ANSI and ASCII modes are supported.  Both remote and
   local use is supported.  Remote use is intended for BBS sysops who
   want to let users access a CD-ROM they own.  Local use is great
   for everyone!


   ANSI/ASCII Support

   The door is told whether a user wants ANSI via the command line
   switch -A<n>.  If <n> is 1, all system text files that are
   displayed (help files, intro, etc) a .ANS extension will be
   searched for first.  If a .ANS file is not found then the door
   will look for a .ASC file and display it.  If the user does not
   have ANSI, .ASC files will always be displayed.  If the -A switch
   is not on the command line, the program will then use the
   ANSI_DEFAULT item in the config file.


   Transfering Files

   The main impetus for writing this door was due to the fact that
   I did not want to add umpteen-million groups of files to my BBS
   but still wanted to use the BBS download capabilities, download
   ratio checking, security, etc.

   The solution was to have the user choose what files he/she wants
   off of the CD-ROM, and have them transferred into ONE or more CD-ROM
   Transfer areas in the BBS for later downloading.  This adds one step
   for the user to get CD-ROM files, but the users on my board seem
   to like the doors... though nothing is ever perfect, and I am
   always looking for ways to improve the door.


   Flexibility

   This program allows for people to use pre-created modules to
   access CD-ROMS and create their own.  Creating a new module is as
   simple as creating a few text files... no programming involved.
   It also allows one to access and search multiple CD-ROM's...
   It is simple as creating combined lists for files and organizing
   them... see Installation below for more details.


   Local/Remote Use

   The program acts a little differently for local and remote use.
   For local use, there is an added option, unpack cd file to a
   specified path.  The transfer option is also slightly different
   for local use, a path is entered where remote users have no
   choice, it is specified in the config file instead for BBS
   security.

   It also watches remote users time, gives a warning at five minutes and
   bumps him/her back into the BBS a two minutes.


   Viewing Text Files

   ROMDOOR also lets local/remote users view text files that are
   contained on the CD-ROM.  One nice thing about the package is when
   you specify a file to look at, unpack or transfer, all you have to do
   is give it the filename without having to know what subdirectory it
   is on.  And some CD's have quite a few directories.

   Local/Remote archive file manipulation

   ROMDOOR also lets local/remote users view archive files by
   executing the archive shell specified in the configuration file
   (see config section below).

* Installation *

   There is one big factor that will determine how this thing is installed.
   ROMDOOR was developed to allow people to create a "front end" to
   search thru and extract files on a shareware type CD-ROM.  The factor
   is whether you are creating a new CD door... or you are using one
   someone else has already created.  I call each set of these CD-ROM specific
   data files a "module".  If you have a module for the CD you want to access,
   there should be virtually no installation or messing with the config
   files unless you want to change how it was done.

   - Make sure ansi.sys or equivalent is in the config.sys file, for local
     use.

   Quick Install for those using a precreated module

     o  Make a directory for the door
     o  Uncompress the files of the module into that directory
     o  Uncompress the files of romdoor into that directory

   Creating a new module

     o  Make a subdirectory for the door
     o  Create description file for each area (should be supplied with CD)
     o  Create database file list for romcopy (see romcopy.doc)
     o  Create catalog file
     o  Create config file
     o  Create/Modify other ansi/ascii support files
     o  Create the batch file that BBS will invoke to start the door
        (see Things NOT covered by the Door below)
     o  Create a batch file for you (and possibly others) to run
        locally

     Please, if you create a decent module, upload it to my BBS so I
     can make it availible FREQable for all...

   Catalog File

   The catalog file is simply a list of the different file areas
   availible.  Give it any format you like, as long as the areas
   are labeled 1-whatever and are in the same order as the config
   file AREA commands (see AREA below).  The system supports
   ANSI/ASCII versions of the file, and the filename is specified
   in the config file by the CATALOG statement.


* Configuration File (Default of ANSIDOOR.CFG) *

   The configuration file contains setup info which differs from
   one BBS to the next.  The following items are need to be in the
   config file:

      XFER_DEST D:\RA\CARRS
      XFER_DESC D:\RA\CARRS\FILES.BBS
      BBS_NAME "The Data Dungeon!"
      AREA 001.cat  Communications
      AREA 002.cat  Games
      DECOMP_COMMAND "pkunzip -d "
      CATALOG catalog
      INTRO carrs
      DEF_EXT .zip
      CDROM_NAME "CARRS Bonanza"
      ALL_FILES_LIST filelist.dat

   An explanation of each follows:

   XFER_DEST:   For Remote mode, this is the directory where users will
                transfer files from the CD to.

   XFER_DESC:   This is the file description list for the transfer directory.
                Many BBS packages support ASCII lists for the files
                in each different area (ex files.bbs).  ROMDOOR will
                add an entry for each file transfered from the CD.

   AREA:        This creates another area for the CD.  The first parameter
                is the path to the files description list for that area,
                and the rest of the line is the name of the area.  There should
                be one of these statements for every file area you want to
                have.  Since you can give a path to the file description, you
                can use the one on the CD, or move it to your hard drive.
                Moving it to your hard drive dramatically improves access
                time.

                *** TIP:  You don't have to use the file "areas" that are
                  on the CD.  If you don't like how things are arranged
                  on the CD, split up the description files how you
                  would like to see it done.  For example, if there are a
                  bunch of BASIC game descriptions in the Games directory of
                  your cd rom, you could make a new area called BASIC games,
                  and split the games file description into two description
                  files on your hard drive.


   DECOMP_COMMAND:  The command to decompress a file.  The example given
                    is pkzip, but you will want to use whatever is appropriate
                    for that CD.  Only one type supported for now.
                    With the next release I would like to make it
                    based on extension.


   CATALOG:     The name of the catalog file.  If no extension is given, the
                door will look for <name>.ans if the person has ANSI,
                and then <name>.asc.  This is displayed when the user
                needs/wants to change file areas.

   INTRO:       The name of the intro file.  If no extension is given, the
                door will look for <name>.ans if the person has ANSI,
                and then <name>.asc.  This file is displayed when the door
                is first called.

   DEF_EXT:     This tells ROMDOOR what extension to default to when
                the user enters no extension on a transfer or unpack.

   DEF_TEXT_EXT: This tells ROMDOOR what extension to default to when
                 the user enters no extension on a view text file.

   CDROM_NAME:  Yep, you guessed it.  Surround the name in quotes.
   BBS_NAME:    Yep, you guessed it.  Surround the name in quotes.

   ALL_FILES_LIST:  This is the name and path to the database file
                    containing a list of all the files for the CD rom and
                    where they are.  This is created with the
                    MAKEDIR.EXE utility.

   TEMP_FILE: Temporary file created for various operations.  Make
              this point to a VDISK if you have one setup.  Ex.
              E:\TEMP.$$$  Note that this is the FULL filename,
              not just the path.

   LOCAL_COMP_UTL:  Local compression utility.  This will get called
                    when running in local mode and the user asks to
                    view contents of a compressed file.  The
                    filename will be passed to the utility.

   REMOTE_COMP_UTL: Remote compression utility.  Same as above... but
                    the utility should work redirection.

   Comment lines are allowed in the config file and are identified
   with a semicolon in the first column.


* Command Line Switches *

   -A<n>   where <n> is 0 for ASCII mode and 1 for ANSI mode
   -N<n>   where <n> is the users first name
   -T<n>   where <n> is the amount of time left on system
   -R<n>   where <n> is 0 for LOCAL (default) mode and 1 for REMOTE mode
   -C<n>   where <n> is the name of the config file to use, if none is
                        specified, ANSIDOOR.CFG is used as a default.
   -D      debug mode.

   If you are calling this program from a Remote Access, you can do
   something like (see RA docs for complete descriptions on command
   line expansion macros):

     romdoor -A*G -T*T -N*N



* TEXT Support Files *

    HELP.ANS/ASC  This file is displayed when the user asks for help from
                  the main menu.

FILESAVE.ANS/ASC  Displayed when user has transferred a file to the
                  BBS for later download in the current door session.


* Things NOT covered by the Door *

  CD Watchdogging...  Most want their system to recover from a
   user hanging up, and this simply reboots the BBS if the carrier detect
   signal from the modem desists.  I did not write it in to the door
   due to the fact that today's FOSSIL's usally have it built in.  I
   am trying BNU at the moment, and it has worked flawlessly.

  I/O Redirection...  Video output and keyboard input is done through the
   standard channels.  This works nicely for running it locally, but
   when you want to allow a remote user to run it, all input/output
   needs to be routed though the com port...  there are two ways
   to do this.  The first way is to use the CTTY COM1 directive
   before the execution of the door, and the CTTY CON after the
   door executes.  I use a device driver called GATEWAY that allows
   for simultaneous input/output locally AND through the COM port.
   Therefore, my batch file that starts the door looks like this:

       @echo off
       break off
       bnu /W=0+                          ; Turn Watchdogging ON
       ctty gate1                         ; Redirect input/output
       d:
       cd \ra\rbbsbox                     ; Switch to the doors directory
       romdoor -C %1 %2 %3 %4 %5 %6          ; Start the DOOR
       ctty con                           ; Redirect input/output back
       bnu /W=0-                          ; Turn Watchdogging OFF
       cd \ra                             ; Switch back to the BBS dir


* Future Enhancements *

  There are a TON of things I would like to add to this thing, but like
  all projects, if I can't get the funding through my users,  I can't
  justify putting much into the project, so please register!  Enhancements
  I would like to see in this thing include:

    o   Chat while in remote mode
    o   Direct downloading from within door
    o   Transfer times for files

  If you think of something, let me know, and please Register!  Its
  the only way I can justify spending more time on the door.


* Registering *

Single site registration...

  You can use this door to drive a 1000 CD's, as long as it is on one
  machine.  Please register one copy per machine @ 15$ a copy.
  Please let me know where you got the program, and what disk size
  you would like (5 1/4" or 3 1/2").

  Registering provides me with a good reason to work on the project, and
  provides you with the following:

   o   The latest version of ROMDOOR
   o   Modules for ROMDOOR
   o   Online support on the HSF BBS (see ad below)
   o   No pause at the beginning of each run, text changed to
        registered with your name/company name

   Send registration to:

     James Snowden
     Helix Software Foundation
     PO Box 693
     Essex Junction, VT 05453
     Attn: ROMDOOR


CD ROM Producers...

  Please contact me!  I am ALWAYS willing to make a deal with people
  creating the latest in CD technologies.

┌┬──┬───────────────────────────┬──┬┐
│├──┘   The Data Dungeon BBS!   └──┤│
││          1-802-899-4988         ││        24 Hours,
││     Over 2 Gigabytes of Files!  ││        7 Days a Week,
││       6 Disk CD-ROM Player      ││        365 Days a Year!
││       14400 HST/V32 8-N-1       ││
│├──┐      FidoNet 1:325/123    ┌──┤│
└┴──┴───────────────────────────┴──┴┘


* Disclaimer *

    There is no warranty, written or implied.  Helix Software
 Foundataion is not responsible for any damage in the use or misuse
 of this software and is distributed in an AS-IS state.  This does
 NOT mean that I am uninterested in the enhancements you would like
 to see,  please send them to me via FidoNet or via US Mail...


Special thanks...

    All the users on my system for their patience, Bob Hall and all
    of other beta testers!